The present invention relates to thin provisioning storage systems, and more specifically, to prioritization of virtual volumes to take offline in a thin provisioning system.
Thin provisioning is a technology that allows large volumes of storage to be presented through a “virtual” disk, whilst the underlying storage used by this volume is kept to a minimum. The way this is achieved is by not provisioning all storage on physical disk creation and only expanding the physical disk as and when storage is required. If a disk has only been partially used by the user, only part of the volume is allocated resulting in far lower storage allocation requirements for these volumes.
Thin provisioning makes use of a forward lookup map: a data structure that maps a virtual address to where on the physical domain the underlying storage for that virtual address write lives. Typically, this data structure maps virtual address “grains” (fixed size chunks of virtual space) to the physical domain. A reverse-lookup mapping is also typically maintained, either for garbage collection purposes, or to allow a physical-to-virtual domain lookup in the event that data corruption should occur. This reverse lookup is typically maintained on a reverse lookup tree (RLT) or table data structure.
Over allocation is the notion that one can have far more storage virtually allocated than is physically available to the user. This can mean that whilst 10 terabytes of storage is presented to a collection of servers, there may only be 1 terabyte worth of physical domain. So long as the storage requested from the servers (and the metadata) does not exceed 1 terabyte, this will hit no issues. However, should storage requirements exceed the available storage, typical behavior would be to take the thin provisioned volumes offline or place them into a read-only mode.
Space in the physical volumes that is no longer being referenced by a virtual address can be reused by a garbage collection mechanism. Typically, garbage collection operates by having allocation regions that can support multiple writes. When an allocation region has many empty spaces in it, it could be subjected to garbage collection. Garbage collection typically will: (i) copy the data inside of the allocation region, (ii) update the forward lookup mapping to mark the new location of copied data, and (iii) free the allocation region for reuse, or to be returned to the storage pool.